Since its delivery at TEDxPugetSound in 2009, Simon Sinek’s Start with why – How great leaders inspire action YouTube video has been viewed over 17 million times. Sinek introduces the concept of the golden circle of communication, highlighting how great leaders – both individuals and organizations – lead the same way. Inspired organizations communicate from the inside out with clarity, starting with “why” (their purpose, cause, or belief), following with “how” (how they do it), and only then providing the “what.” Systems engineering has its own golden circle, and while there are some key distinctions from Sinek’s context, the concepts of why, how, and what are essential.
Good systems engineering – in fact good engineering – does not begin in the solution space, the “what” we are providing. Instead, it begins in the problem space, studying the problem (or opportunity) from multiple perspectives in order to understand it to the greatest degree possible. Too often, we find ourselves responding to well-meaning requirements that reflect symptoms of the problem but not the real problem itself. A classic systems engineering technique is to progressively ask five whys to elicit the real issue and the nuanced considerations behind the requirement statements offered. So as Sinek counsels, systems engineering too should not start with “what” – the solution – but instead start with “why.” Otherwise, we run the risk of delivering an excellent solution to the wrong problem, resulting in ineffective capabilities in a military context and market failures in the commercial space.
But the “why” of systems engineering goes beyond the first statement of need. Throughout the engineering process, the project team makes countless decisions that clarify the scope of the problem, assumptions made, approaches adopted, and the ultimate design itself. All of these decisions – more specifically, the questions raised, the alternatives considered, and the supporting rationale – become part of the why that should be captured and preserved. The why of the journey provides key context for the design, is critical to establishing trust that decisions are good ones, and becomes essential when effectively addressing mid-cycle requirement changes, technology insertions, and next-generation systems. Systems engineers should not only start with why, they must also serve as the guardians of why – both the why that initiates the project and the why of the engineering journey.
If we simply stayed in the domain of “why,” we would understand the problem and the critical interactions. However, engineering is about more than understanding. Engineering is interventional, and for systems engineering, the highest leverage for solving the problem comes not from the “what” of the solution (the system we deliver), but from the logical “how.” Often our instinct is to jump from a statement of need to a specific implementation. In the case of simple problems with precedented solutions and little change in needs or technology, this allows us to move forward quickly. But systems engineers address complicated and complex problems – not simple ones – and today’s world is marked by change and an accelerating technology insertion cycle rather than stability. If we leap from “why” to “what,” we lock into old approaches and old technologies, as well as old approaches to new problems in an evolving context – an engineering strategy which will rarely deliver the right solution.
Moving from requirements to behavior – the “how” of systems – allows us to understand our approach to solving the problem logically before we decide how to solve the problem physically. Not only does this enable better problem understanding and expand the scope of available solutions, it also drives innovation. New technologies implemented at the physical level refine existing solutions and bring incremental benefit. Bringing new combinations of ideas, approaches, and technologies together is at the heart of innovation (for example, ride-sharing vs taxi services). This is enabled by thinking through the system behavior which we can then allocate to the physical solution in unprecedented ways.
Ultimately, we do specify and deliver systems – the “what” to meet the stated need. Systems engineers are encouraged to begin with the end in mind. That end is not the journey, the model, the specification, or even the system itself. That end is delivering the required value to the customer and the stakeholders in an effective and efficient manner. It is the “what” – the system of interest – that enables us to deliver that value.
Much as Sinek notes in his discussion of leadership and communication, systems engineers have their own why, how, and what. (Obviously, there is far more than that to good systems engineering – risk identification and mitigation, validation to ensure we are solving the right problem, verification to ensure we are solving the problem right, etc. – but why, how, and what do rise to the top.) However, stopping with the parallels overlooks several key insights.
First, for the sake of simplicity, Sinek communicates his golden circle of communication as a series of concentric circles proceeding outward from “why” to “how” to “what.” In the process, it’s conceptualized in a very serial manner. The why, how, and what of good systems engineering is anything but serial. Systems engineering by its very nature focuses on interrelationships, and those interrelationships exist not only within the system but also within the why, how, and what of the design. At the very least, systems engineering is iterative, and it is far better to see the why, how, and what as interlaced and concurrent. The why at a lower level of detail is determined by the solution path pursued. (Selecting a given logical approach and physical architecture raises requirements questions that are irrelevant in other solutions).
Likewise, though we are encouraged to think of the functional/behavioral architecture independent of the implementation technology, the behavioral and physical architectures are tightly coupled. Therefore, systems engineering must recognize, capture, and leverage the interconnected nature of systems engineering approaches and systems architectures. We can choose processes, methods, and tools that silo our team and our thinking, or we can embrace the concurrency and connectedness for greater results. For this reason, an integrated layered approach – moving from one level of detail to the next – proves far more resilient and effective than thinking of requirements, behavior, and physical architecture in a waterfall mentality.
Second, the why, how, and what of systems engineering is not limited to system architecture itself. Operational architecture – or mission engineering when working in a system of systems world – follows the same why/how/what pattern as it moves from mission through the analysis of operational activities and the corresponding performers. The terminology may differ, but the concepts are the same. More importantly, the output of the operational architecture effort is the definition of needed capabilities, a definition which drives the requirements that start the “why” of the system architecture. So the “what” at one level ultimately becomes the “why” at the next.
If we elevate to strategic planning, we see the pattern once more as we respond to organizational needs in the context of strategic guidance (the why) with portfolio definition and management to drive new products and organizational capabilities (the what). From strategy through operational considerations to the system itself, the why, how, what of systems engineering is at least recursive if not fractal in nature. Expanding our scope, understanding the interrelationships from strategy to system, and managing this effectively brings even more value to systems engineering.
As we live in the information age where each of us sells ideas and concepts, Sinek’s “Start with Why” is relevant to far more than just leaders. It’s worth investing 18 minutes to watch this entertaining and compelling video so that we can communicate more effectively, better enabling others to understand and connect with our ideas. For systems engineers, seeing why/how/what in our context, and leveraging the golden circle of systems engineering can bring clarity to our approaches and enable us to more effectively deliver solutions in this age of complexity.
